% === Part one ===
\newpage
\chapter{Présentation du contexte}

\section{Smile - acteur majeur du web open-source européen}

\subsection{L'open-source et le web}

\subsubsection{La naissance du web}

Le web ---~aussi connu sous le nom de World Wide Web~--- tel que tous nous le connaissons aujourd'hui a pris forme dans les années 90. Il s'agissait au début de créer un système d'échange d'informations et de documents utilisant Internet\footnote{Il est intéressant de noter que même si on les confond souvent les deux, le web ne désigne que la couche applicative d'Internet}, projet initialisé par des informaticiens du CERN\footnote{Organisation Européenne pour la Recherche Nucléaire} : Tim Berners-Lee et Robert Cailliau. 

Petit à petit, ils vont être à la base des technologies fondatrices du web : les URL, le protocole HTTP, et le langage de balises HTML. En à peine quelques années, le web commence à se démocratiser avec l'apparition des premiers navigateurs (NCSA Mosaic) et des premiers serveurs web (NCSA HTTPd).

Évoluant à présent de lui même, le web prend son envol, suivi de près par les grands groupes tel Microsoft, qui entre-voient son potentiel immense. Le \textit{World Wide Web Consoritum} (W3C)\footnote{http://www.w3.org/} est créé par les fondateurs du web pour essayer de conserver son unité et l'aider à développer tout son potentiel. \cite{w3chistorique}

\subsubsection{La standardisation du web}

Afin de parvenir à ses fins, le W3C décide de se lancer dans la rédaction et la maintenance de recommandations sur les technologies à l'origine du web. Celles-ci ont pour but d'assurer un web uniforme, et accessible à tout visiteur, quelle que soit son interface. Cependant, la fondation ne faisait pas le poids à cette époque contre les géants de l'informatique qui, comme Microsoft avec Internet Explorer, ont facilement dévié de ces spécifications pour intégrer leur propre vision du web.

Depuis, les navigateurs se sont multipliés, à tel point que l'on compte cinq familles principales de navigateurs (cf figure \ref{browsers} ) : Internet Explorer, Firefox, Chrome, Safari, Opéra. Il ne peut pas y avoir un web par famille, et la standardisation est devenue la seule solution possible.

\begin{figure}[h!]
\centering
\includegraphics[width=12cm]{images/browsers.png}
\caption{Les principales familles de navigateurs et leurs parts de marché au cours du temps \cite{w3cbrowsers}}
\label{browsers}
\end{figure} 

Cette hétérogénéité persiste encore de nos jours, même si elle décroit fortement. En attendant, il est nécessaire que tous les acteurs du web essayent de faire de leur mieux pour palier aux différences entre les navigateurs.

\subsubsection{Open-source vs logiciel libre}

Le web est très vite devenu un formidable outil de partage des données. Très vite, des techniques de développement collaboratifs sont apparues, et le web permettait facilement de gérer des projets dont les développeurs étaient totalement décentralisés. Des millions de ces projets de tailles et types très variés virent le jour, dont beaucoup n'étaient pas liés au monde de l'industrie ou du profit. 

Ces programmes, considérés simplement comme gratuits pour beaucoup, sont souvent qualifiés d'open-source ou de logiciel libre. Même s'il existe des nuances entre ces deux notions, le but premier était de protéger ces logiciels de toute personne externe voulant s'approprier le code pour en faire des bénéfices. 

Un logiciel libre est, d'après la \textit{Free Software Fundation}, un logiciel que l'on peut exécuter, étudier, redistribuer et modifier. Il n'est pas possible de restreindre une de ces libertés. Néanmoins, ça n'empêche pas le logiciel d'être rentable notamment grâce aux services proposés autour, ou simplement au coût du développement.

Posséder un logiciel dit \og open-source \fg{} permet principalement\footnote{Pour une définition plus complète, voir \cite{opensourcedoc}.} de, comme son nom l'indique, consulter ses sources, éventuellement les modifier et les redistribuer. Tout comme un logiciel libre, ça ne signifie pas forcément être gratuit. Cette notion diffère de la précédente dans le sens où elle se rapproche plus du monde du développement alors que la vision logiciel libre concerne directement l'utilisateur final.

\subsubsection{Une économie solide}

Comme nous le disions dans le précédant paragraphe, ce n'est pas parce que le code ou le logiciel est libre que ça signifie forcément sa gratuité. Il existe tout un écosystème d'entreprises autour de l'open-source. Étant donné qu'il ne peut plus y avoir de licence payante, le prix total d'une telle application est fortement diminuée pour des avantages importants. La facturation d'une application open-source est donc ainsi beaucoup plus lié à la création et à la maintenance de l'application. Même si une certaine partie des développeurs peut rester bénévole, dans le cas d'une application totalement libre, il peut exister des services payants qui vont se greffer autour pour proposer des améliorations, des développements spécifiques, ... Une fois que le client possède l'application modifiée, il est libre d'en faire ce qu'il veut sans contraintes puisqu'il s'agit toujours d'une application open-source.

De cette façon, le développeur ne fournit pratiquement jamais son programme directement à l'utilisateur final. Un certain nombre d'autres acteurs est susceptible de faire retentir un coût sur l'utilisateur. Voici le schéma d'un modèle assez générique.

\begin{figure}[h!]
\centering
\includegraphics[width=13cm]{images/fluxopensourcenb.png}
\caption[Flux du modèle économique open source]{Flux de prestations (\textcolor{prestations}{$ \blacksquare $}), de code source (\textcolor{sourcecode}{$ \blacksquare $}) et d'argent (\textcolor{money}{$ \blacksquare $}) dans le modèle open source. D'après \cite{lbDecouvrirOpenSource}.}
\end{figure} 

\begin{description}
 \item[Fondations :] Il s'agit d'organisations à but non lucratif. Elles stimulent et pilotent de grands projets open source, fédèrent une communauté et diffusent le programme et le code source. Des exemples de fondations sont la fondation Apache, la fondation Mozilla et la fondation Eclipse.
  \item[Distributeurs :] Ils sélectionnent des outils, des composants, et ils en assurent la distribution et le support. Généralement, ils ont aussi une activité d'éditeurs. Mandriva est un exemple de distributeur.
  \item[Éditeurs :] Ils créent un produit logiciel, et le distribuent, totalement ou partiellement, sous licence open source. Ils ont une activité commerciale, consistant à assurer la promotion de leur produit, mais proposent également un support (payant ou non selon la licence choisie par l'utilisateur). Parmi les éditeurs open source, citons MySQL, eZ Systems, Alfresco et Magento Inc., anciennement Varien, dont nous reparlerons plus loin.
  \item[Prestataires :] Ils vendent des services, qui peuvent être du conseil, de l'intégration, du support, de la formation, de l'hébergement, etc. C'est à cette catégorie qu'appartient Smile, en tant qu'intégrateur (mais aussi du fait de ses pôles conseil, TMA et hébergement).
 \end{description}


Les éditeurs open source choisissent parfois de proposer deux types de licence au lieu d'un : le premier est gratuit, destiné notamment aux développeurs ou aux particuliers. D'autres licences, payantes, incluent diverses prestations parmi lesquelles on compte notamment du support, des fonctionnalités plus étendues, etc. 

\subsection{Smile}

\subsubsection{Présentation}
Smile (voir figure \ref{fig_logosmile}) est une société française d'ingénierie informatique, fondée en 1991. Intégration de solutions open source et ingénierie internet constituent son c\oe{}ur de métier. Smile dispose de compétences sur une vaste gamme de solutions :

\begin{itemize}
 \item la gestion de contenu web (\textit{Content Management System}, plus connus sous le nom de CMS),
 \item les portails,
 \item les systèmes de gestion documentaire ou ECM (\textit{enterprise content management}), gestion de contenus d'entreprise (courriers, courriels, télécopies, contrats, etc.),
 \item les ERP (\textit{enterprise resource planing}, ou progiciels de gestion intégrés ---~de tels logiciels gèrent l'ensemble des processus opérationnels d'une entreprise) ou des outils de CRM (\textit{client relationship management}, gestion de la relation client),
 \item les solutions de commerce électronique (ou e-commerce), dont nous reparlerons plus loin,
 \item les systèmes décisionnels,
 \item les solutions système et infrastructure...
\end{itemize}

\begin{figure}[h!]
 \begin{center}
 \includegraphics[width=8cm]{./style/images/smile.png}
\end{center}
\caption[Le logo de Smile]{Le logo de Smile}
\label{fig_logosmile}
\end{figure} 

Smile dispose également d'une agence de création graphique (Smile interactive), propose des services de conseil et d'assistance à maîtrise d'ouvrage (Smile consulting), ainsi que des services système (virtualisation, hébergement, surveillance et exploitation des plateformes, etc.) et de la maintenance (on parle de TMA, tierce maintenance applicative).

Par ailleurs, Smile est membre de l'APRIL\footnote{\url{http://www.april.org/}} (association pour la promotion et la défense du logiciel libre) ainsi que d'autres associations régionales de professionnels du logiciel libre. Elle mène, de plus, une veille technologique active, afin de découvrir les produits les plus prometteurs de l'open source. L'idée est de proposer aux clients des solutions aussi abouties et aussi robustes que possible.

\section{Planning et déroulement du stage}

Mon stage s'est principalement déroulé en deux grandes parties : formation et développement.

\subsection{Formation et préparation du stage}

Dans un premier temps j'ai reçu une formation technique très poussée. En effet, la politique de Smile est de privilégier les jeunes diplômés et de leur donner une formation robuste. Ainsi l'entreprise peut s'appuyer sur une main d'œuvre dont elle connait et maîtrise en grande partie les compétences métier. Des formations, ouvertes à tous, sont disponibles que ce soit par visio-conférence ou directement sur place, au sein des agences. De plus dans le cas des stagiaires, un budget spécial d'auto-formation leur est alloué.

\subsubsection{A la découverte de Symfony}

Dans mon cas, j'ai ainsi commencé par de l'auto-formation sur le framework Symfony\footnote{Voir \ref{symfony}}, que j'ai pu mettre en pratique pendant quelque temps sur un projet Symfony. Je ne donnerai que peu d'informations sur ce projet puisque j'y ai peu participé et qu'il est en partie confidentiel. Il m'a principalement servi d'entrainement avant de me lancer plus concrètement sur un projet. J'ai donc développé des petits algorithmes de watermarking pour fichiers Epub\footnote{Basé principalement sur des fichiers au format XML (\textit{Extensible Markup Language} \cite{xml}), le format Epub est un des principaux standard du monde du livre numérique.}. 

Le watermarking est une technique consistant à cacher des informations dans un document comme une image ou un texte. A partir de là toutes les solutions sont envisageables. Le plus sûr, pour que l'information soit persistante, est donc de multiplier les watermarks et d'utiliser différents procédés. L'application que j'ai développée utilise donc des attributs XML inutilisés par le format pour cacher des informations, ainsi que les caractères non pris en compte par le XML (les espaces blancs entre les balises notamment).

\subsubsection{Une formation homogène}

Smile offre ensuite à tous ses stagiaires une formation globale dans les locaux de la maison mère, à Paris. Cette formation englobe de larges sujets autour du développement informatique, de la gestion de projet et de la création de sites web. Elle a pour but de donner un niveau homogène à tous les jeunes arrivants afin de garantir un socle de base optimal pour travailler. C'est aussi l'occasion de leur donner une meilleure vision de l'entreprise afin de les fidéliser. De cette manière beaucoup de stagiaires sont embauchés à la fin de leurs études. Smile a en effet tout à y gagner puisqu'un stage est une période d'essai peu coûteuse, mais de cette façon le stage devient tout aussi inestimable pour l'étudiant, et cela quelque soit sa décision de rester ou non.

Cette formation globale est composée de sous-formations sur les outils quotidiens d'un développeur web : SVN, l'IDE, ...\footnote{Voir \ref{outilsdev}.} mais aussi sur les méthodes de développement à utiliser pour \og bien \fg coder\footnote{Voir \ref{biencoder}.}. Un des principaux atouts de Smile est en effet sa philosophie de développement qui tient à respecter au mieux les standards actuels du web. Les applications ainsi développées sont plus robustes, plus fiables, et plus facilement maintenables.

\subsection{Projet Eovi : développement de l'application}

Une fois ma formation achevée, j'ai été affecté à un nouveau projet en tant que développeur web. L'équipe se compose donc de différents acteurs et leurs rôles au sein du projet sont les suivants :

\begin{itemize}
\item le client : il établit la demande et spécifie ses besoins ;
\item le chef de projet dialogue avec le client et traduit leurs attentes aux développeurs ;
\item le directeur qualité supervise le projet pour s'assurer que tout est fait dans les normes ;
\item les développeurs et graphistes réalisent l'application en soi.
\end{itemize}

Chez Smile, la plupart des projets fonctionnent suivant le modèle classique du cycle en V (voir fig. \ref{figcyclev}).

\begin{figure}
\centering
\includegraphics[width=13cm]{images/Cycle_en_V.jpg}
\caption{Le modèle générique du cycle en V}
\label{figcyclev}
\end{figure}

Les grandes étapes sont toujours les mêmes, malgré quelques variations dans leurs noms.

\subsubsection{L'expression des besoins, ou vente du projet}

Cette étape est variable suivant la nature de la demande. Il peut s'agir d'un appel d'offre, ou de simple prospection, mais le résultat final est toujours le même : un cahier des charges des besoins client. C'est à l'équipe commerciale d'aider le client à le mettre en place. Il est intéressant de noter que chez Smile, les commerciaux sont très souvent d'anciens techniciens, ce qui leur confère la capacité de vendre au mieux les technologies (ni trop cher, ni pas assez).

\subsubsection{Les spécification fonctionnelles}

Toujours réalisées en accord avec le client, ces documents vont vraiment définir point par point ce que le client attend. Il s'agit de préciser au mieux le comportement de l'application pour guider les développeurs dans leur tâche, et cette fois c'est le chef de projet qui  a la charge de les faire valider.

\subsubsection{La conception technique}

Selon les projets (principalement selon leurs tailles) elle est plus ou moins décidé en accord entre le chef de projet et ses développeurs. Il va au moins choisir les outils de base (frameworks, logiciels à intégrer, ...) tandis que son équipe se doit de le conseiller sur les difficultés possibles afin d'établir au mieux le planning. 

\subsubsection{Le développement de l'application}

Une fois la trame principale bien définie, le développeur va devoir adapter la solution retenue de la meilleure façon possible. Le chef de projet reste toujours en amont en cas de problème grave pour trouver une solution, mais la plupart du temps c'est au développeur de contourner la difficulté.

\subsubsection{La recette interne et client}

\label{recette}

Une fois le développement terminé, il faut valider ce qui a été fait. Elle doit se faire des deux cotés : par la SSII et par le client afin de valider les réalisations ainsi que le respect des spécifications. En effet, il n'est pas rare que sur des détails parfois bloquants, l'application ne se comporte pas comme prévue.

\subsubsection{La mise en production}

Enfin, une fois que toutes les étapes ont été validées, il est temps de passer à la mise en production. La principale source de problèmes à cette étape est due au changement de configuration. En effet, on arrive en générale sur une nouvelle machine et il faut définir des paramètres un peu différents de tout ce qui a été testé précédemment pour lancer l'application.

\subsubsection{Les t\^aches d'un développeur}

Pendant ce projet, j'ai ainsi pu être confronté à une grande partie de la vie d'un projet : de la conception à la mise en production, en passant par le développement et la recette. 

\section{Objectifs du stage - Description du projet Eovi}

\subsection{Eovi}

Ce projet a été commandité par le groupe Eovi mutuelles. Il s'agit d'un rassemblement de mutuelles des régions du centre et du sud-est.

\subsection{Application Web}

L'application demandée possède deux buts principaux :

\begin{itemize}
\item la présentation de la mutuelle, avec un maximum d'informations disponibles ;
\item la possibilité d'établir des devis et de souscrire aux garanties proposées par Eovi.
\end{itemize}

J'ai donc été attaché au développement du tarificateur que j'ai réalisé en la quasi-totalité. Il doit être capable proposer des devis et souscriptions à des garanties rangées par offres, dont les montants varient en fonction du client.

Ce présent rapport ne détaillera que les spécifications et la réalisation de cette partie.

\subsubsection{La vitrine de présentation}

Comme annoncé plus haut, la première partie de l'application doit être une application modulable capable d'afficher du contenu décrivant Eovi Mutuelle. Pour cela, nous avons utilisé un système de gestion de contenu existant (plus connu sous l'acronyme anglais \textit{CMS}), eZPublish, pour l'adapter aux besoins du client.

De cette manière, Eovi dispose d'une interface d'administration à partir de laquelle ils peuvent modifier des pages ou ajouter du contenu au site.

\subsubsection{La génération de devis}

Le tarificateur est le cœur de l'application. C'est ici que sont calculés les devis pour d'éventuels futurs  clients. Le visiteur va donc rentrer sur le site un certain nombre d'informations, notamment :

\begin{itemize}
\item sa date de naissance ;
\item son code postal ;
\item la date d'adhésion qu'il souhaite ;
\item s'il a un conjoint ou non (ainsi qu'éventuellement la date de naissance du conjoint) ;
\item le nombre et la date de naissance de ses enfants.
\end{itemize}

De cette façon, Eovi dispose de suffisamment d'informations pour établir un devis, bien que quelques informations supplémentaires soient demandées (nom, adresse ...). L'utilisateur choisit la garantie qui lui convient le mieux, puis un PDF récapitulatif lui est présenté. Il peut éventuellement y souscrire en ligne via l'API de paiement de la Caisse d'Epargne : SP+.

Une partie export/administration doit également permettre à Eovi de récupérer et manipuler les données (dans le cas de textes ou valeurs paramétrables).

\subsection{Spécifications tarificateur}

La rédaction des spécifications s'est faite surtout sous forme de schémas et de règles de gestion. Libre ensuite au développeur de l'adapter à une réalité technique au moment de la conception, en accord avec le chef de projet.

Pour éviter trop de redondance, je n'inclurai pas d'image ou de schéma ici, mais vous pouvez les consulter dans la partie \ref{rendu}, où est présenté le rendu final. Je ne vais pas non plus donner le détail de chaque bloc à développer mais plutôt présenter les principales fonctionnalités de chaque page, en précisant les points qui peuvent se révéler plus complexes.

L'application se présente sous la forme d'un tunnel de formulaires. Durant tout son déroulement, l'utilisateur doit pouvoir revenir à une étape précédente pour modifier ses informations.

\subsubsection{Calcul d'un tarif}

La partie la plus importante de cette application est bien-s\^ur l'algorithme de calcul du tarif proposé à un client. Il se base sur plusieurs constantes et notions :

\begin{itemize}
\item le millésime du souscripteur, $An$, qui correspond à la différence entre l'année de sa date de naissance et de la date d'adhésion qu'il demande ;
\item un coefficient départemental, $CD$, défini par Eovi et dépendant du code postal fourni par le souscripteur ;
\item un tarif pivot, $C_{46}$, défini par Eovi pour chaque garantie.
\item éventuellement une réduction pour conjoint, $reductionConjoint$, définie par Eovi. 
\end{itemize}

A partir de ces données, on peut donc calculer le $tarifSouscripteur$ suivant ces règles :

\[ \left \{
\begin{array}{l c l}
18 \leq An \leq 46 & \Rightarrow & tarifSouscripteur = C_{46} \times CD \div 1.02^{46-An} \\
47 \leq An \leq 60 & \Rightarrow & tarifSouscripteur = C_{46} \times CD \times 1.023^{An-46} \\
61 \leq An \leq 80 & \Rightarrow & tarifSouscripteur = C_{46} \times CD \times 1.023^{14} \times 1.025^{An-60}\\
81 \leq An & \Rightarrow & tarifSouscripteur = C_{46} \times CD \times 1.023^{14} \times 1.025^{20}
\end{array}
\right . \]

On calcule ensuite le $tarifConjoint$ en appliquant simplement :

$tarifConjoint = tarifSouscripteur \times reductionConjoint$

Pour le calcul des $tarifEnfant$, une règle similaire est appliquée pour les deux premiers enfants (et les suivants sont gratuits) :

\[ \left \{
\begin{array}{r c l c l}
 & An & = 0 & \Rightarrow & tarifEnfant = 0 \\
1 \leq & An & \leq 18 & \Rightarrow & tarifEnfant = C_{46} \times CD \times 0.56 \\
18 \leq & An & \leq 26 & \Rightarrow & tarifEnfant = C_{46} \times CD \div 1.02^{46-An}
\end{array}
\right . \]

Il suffit ensuite simplement de sommer le tout :

$tarif = tarifSouscripteur + tarifConjoint + \sum tarifEnfant$

\subsubsection{Page profil}

Le but premier de cette page est de recueillir suffisamment d'informations sur le souscripteur pour pouvoir lui proposer un devis. On lui demande ainsi de rentrer :

\begin{itemize}
\item son nom ;
\item son prénom ;
\item sa date de naissance ;
\item son régime général\footnote{La plupart du temps il s'agit d'\og Assuré social \fg{} mais il existe quelques statuts particuliers comme \og Profession libérale\fg{} ou \og Alsace Moselle\fg{}.};
\item son code postal ;
\item son adresse mail ;
\item son numéro de téléphone ;
\item la date d'adhésion qu'il souhaite ;
\item s'il a un conjoint, et si oui, sa date de naissance et son régime obligatoire ;
\item le nombre de ses enfants ainsi que leurs dates de naissance.
\end{itemize}

Afin de s'assurer du bon format des données, il doit y avoir une validation des champs à la fois c\^oté serveur et c\^oté client. De cette manière, il n'est pas possible de rentrer des données aberrantes, ou qui risqueraient de compromettre l'intégrité du serveur\footnote{Par exemple, une injection SQL consiste à entrer dans des champs du code qui arriverait à être exécuté par des moyens détournés. Ainsi il devient possible de prendre le contrôle des données du serveur, ce qui peut avoir de très graves conséquences.}. Certains champs doivent par ailleurs \^etre validés par rapport à d'autres champs sur la m\^eme page (\textit{exemple} : les enfants ne doivent pas avoir plus de 18 ans au moment de l'adhésion).

Ce formulaire se doit d'\^etre dynamique. L'affichage des erreurs dans les champs doit se faire en temps réel et l'affichage des champs pour les enfants et pour le conjoint dépend directement du nombre d'enfants et de l'existence d'un conjoint.

Il faut de plus intégrer \textit{reCaptcha} : l'API\footnote{Une API, ou \textit{Application Programming Interface}, représente l'ensemble des outils rendus disponibles par un programme pour utiliser celui-ci dans un contexte particulier (au sein d'une autre application par exemple).} de Google pour la génération de captcha\footnote{Un captcha est une petite image contenant du texte à priori non lisible par un robot.} pour protéger le site contre des attaques. Un denier détail à prendre en compte est l'ajout de calendriers pour faciliter le choix des dates.

\subsubsection{Page besoins}

Sur cette page, l'utilisateur devra répondre à quelques questions pour ses besoins en hospitalisation, dentaires, optiques et frais médicaux. Ces données n'influencent pas les tarifs mais servent d'autres buts pour Eovi. Éventuellement Eovi peut, après la fin du projet, demander une évolution pour prendre en compte ces champs.

La dernière question concerne le type de garantie souhaité par le souscripteur (bon marché, efficace...). Sa réponse influe directement sur les garanties proposées à la prochaine page.

\subsubsection{Page tarifs}

Une fois les données personnelles saisies et les besoins renseignés, le tarificateur peut proposer un choix entre deux garanties, dont les prix ont été calculés comme indiqué dans la section \og Calcul d'un tarif \fg .

Parmi ces deux garanties, une est recommandée et l'autre alternative, et pour chacune d'elles, des exemples doivent s'afficher décrivant ce qui est remboursé en temps normal et ce qu'elle apporte. Ces exemples doivent être totalement paramétrables par Eovi : ils doivent pouvoir modifier le contenu, en ajouter, et les trier par rubriques.

L'utilisateur peut éventuellement télécharger un PDF récapitulatif, ou se le faire envoyer par mail.

Cette page doit être relativement dynamique : suivant la garantie choisie, les couleurs doivent changer, et son prix doit s'afficher en bas (en plus de là où il est affiché, dans le cadre de la garantie).

\subsubsection{Page finalisation}

Dès qu'une garantie aura été choisie, le tarificateur proposera alors de rentrer plus d'informations pour éventuellement y souscrire. Ces informations concernent principalement le numéro de sécurité sociale et l'adresse des membres de la famille.

La validation du numéro de sécurité sociale se fait par un mécanisme interne au numéro lui m\^eme. En effet, c'est un numéro valide seulement si 

$97 - modulo( numSecu[0:13] \div 97 ) = numSecu[13:15]$

où $numSecu$ est le numéro de sécurité sociale sur 15 chiffres et donc où $numSecu[0:13]$ représente les 13 premiers chiffres et $numSecu[13:15]$ les deux derniers. Il est intéressant de noter que par exemple \textit{0 00 00 00 000 000 97} consistue un numéro valide (utile pour les tests).

Il doit également être possible de choisir pour les enfants s'ils sont attachés au numéro du souscripteur, du conjoint ou s'ils ont leur propre numéro (uniquement dans le cas où ils ont 18 ans ou plus).

\subsubsection{Page souscription}

Une fois tous les champs remplis, une page de récapitulatif des données entrées est présentée au souscripteur qui peut revenir instantanément à une étape pour modifier ses données sans les perdre. 

On lui propose enfin de télécharger des documents PDF explicatifs (dont la liste est administrable) et il peut accepter les conditions de vente et passer au paiement de son choix.

\subsubsection{Page paiement par chèque ou via SP+}

La page de paiement est en réalité séparée en deux pages ayant un contenu similaire : une page de paiement par chèque et une page de paiement via l'API de paiement par carte de la Caisse d'Epargne : SP+.

Cet API consiste en une simple URL appelée qui ouvre une popup vers le site de la Caisse d'Epargne où le paiement est entièrement pris en charge. La génération de l'URL doit être signée par une méthode spécifique de calcul de clef à partir de la clef privée d'Eovi et des paramètres passés à SP+.

Le souscripteur reçoit ensuite le bulletin d'adhésion de la garantie à laquelle il a souscrit.

\subsubsection{Export des données enregistrés}

Eovi possède son propre système d'information qu'ils aimeraient connecter au tarificateur par le biais d'exports de données.

Ces exports doivent se faire dans un format bien précis : par fichiers CSV. Il s'agit simplement de fichiers textes représentant des tableaux. Les lignes sont naturellement délimitées par les retours à la ligne et les colonnes par un délimiteur spécifique (souvent \og ; \fg). Ce format est reconnu par la plupart des tableurs.

\begin{lstlisting}[frame=tblr, caption={Exemple de fichier CSV, la première ligne sert de titre pour les colonnes.}]
nom;prenom;age
De La Fontaine;Jean;42
Abitbol;Georges;69
\end{lstlisting}

\subsubsection{Interface d'administration}

Dans le tarificateur, il existe un certain nombre de données qui doivent pouvoir \^etre paramétrables. Il peut s'agir de textes, de valeurs, ou m\^emes d'objets plus complexes. Voici une liste de ce qui doit \^etre géré via un \textit{backoffice}, ou interface d'administration :

\begin{itemize}
\item certain textes et valeurs entièrement (ex : réduction pour le conjoint, loi informatique et libertés...) ;
\item les coefficients départementaux ;
\item les tarifs pivots des garanties ;
\item les documents téléchargeables à la dernière page ;
\item les exemples de la page de présentation des tarifs.
\end{itemize}

Je n'ai pas développé cette partie, donc je ne détaillerai pas sa réalisation. Néanmoins, il faut savoir que Symonfy possède un outil de génération de backoffice extrêmement puissant et entièrement configurable qui rend sont développement très aisé.

\subsubsection{Le modèle de données}

Ce modèle ne fait pas partie des spécifications mais il a été réalisé par le chef de projet afin de guider le développement et de définir dès le début la façon dont sont représentées les données.

Il intègre tous les champs remplis dans les formulaires dans des tables \og souscripteurs \og conjoints \fg{} et \og enfants \fg , stocke les \og devis \fg{} et \og souscriptions \fg{} et contient quelques tables utilitaires (exemples, statuts, textes paramétrables).

Les tables \textit{eovi\_souscripteur}, \textit{eovi\_enfants} et \textit{eovi\_conjoint} (fig. \ref{figmddfam}) contiennent toutes les informations relatives à la famille du souscripteur.

\begin{figure}[h!]
\centering
\includegraphics[width=14cm]{images/mdd-fam.png}
\caption{Tables représentant une famille}
\label{figmddfam}
\end{figure} 

Ces tables sont liées à quelques autres tables purement utilitaires qui représentent un certain nombre de statuts fixes. Il s'agit des tables \textit{situation\_familiale}, \textit{civilite} et \textit{regimes\_obligatoires} (fig. \ref{figmddutils}). A cela s'ajoute les tables \textit{departements}, \textit{codes\_postaux} et \textit{cantons} qui contiennent des informations générales, utiles pour les calculs comme les liens entre les villes et les codes postaux ou les coefficients départementaux fixés par Eovi.

\begin{figure}[h!]
\centering
\includegraphics[width=14cm]{images/mdd-utils.png}
\caption{Tables utilitaires et statiques}
\label{figmddutils}
\end{figure} 

Les tables \textit{devis\_eovi} et \textit{souscription\_eovi} (fig. \ref{figmdddevis}) contiennent tous les devis et souscriptions enregistrés par le tarificateur.

Les tables \textit{tarif\_eovi}, \textit{offre\_eovi} et \textit{produit\_eovi} (fig. \ref{figmdddevis}) représentent les garanties disponibles. Une garantie est ainsi représentée par la combinaison d'une gamme d'offre et d'un produit, et chaque garantie a son propre tarif. Il existe aussi des documents par produit, dont les URLs sont stockées dans la table \textit{documents\_eovi}.

Les exemples liés à chaque garantie sont contenus dans les tables \textit{tarifs\_exemples}, \textit{eovi\_exemple} et \textit{eovi\_rubrique} (fig. \ref{figmdddevis}).

\begin{figure}[h!]
\centering
\includegraphics[width=14cm]{images/mdd-devis.png}
\caption{Tables représentant les devis enregistrés, les garanties disponibles ainsi que les exemples associés}
\label{figmdddevis}
\end{figure} 

Une dernière table, un peu à part, \textit{eovi\_texte\_parametrable} (fig. \ref{figmddparam}) contient tous les textes paramétrables pouvant être insérés dans le tarificateur à tout moment. Quelques champs supplémentaires permettent de définir des comportements particuliers selon l'implémentation dans le tarificateur.

\begin{figure}[h!]
\centering
\includegraphics[width=5cm]{images/mdd-param.png}
\caption{Table contenant tous les textes paramétrables}
\label{figmddparam}
\end{figure} 

\subsection{Plan de la suite}

Dans la suite de ce rapport, je vais donc vous présenter les principaux outils utilisés et choix faits pour réaliser ce tarificateur.